Sure @andrzej-stencel! Please let me know of you need something.

Thanks for your review 🙏

I've implemented the configurable solution for handling copytruncate rotation as suggested by @andrzej-stencel here. I added a new on_truncate configuration option with three modes to control behavior when a file is detected with the same fingerprint but a smaller size. The ignore mode (default) keeps the original offset and doesn't read any data until the file grows past it, maintaining current behavior and preventing duplicate log ingestion. The read_whole_file mode resets the offset to 0 and reads the entire file from the beginning, ensuring no data loss. The read_new mode updates the offset to the current file size after truncation, allowing only new data to be read.

The truncation detection logic appears in three separate code paths in file.go because the fileconsumer can encounter truncated files at different stages. The open files path handles files actively read in the previous poll cycle. The archive path handles files that haven't been seen for several poll cycles when polls_to_archive is configured. Each path retrieves file metadata differently, so the truncation check needs to happen in all three places to ensure consistent behavior, but please let me know if I'm wrong.

I added comprehensive tests for all three modes and updated the README files for both filelogreceiver and
otlpjsonfilereceiver with detailed explanations of the new configuration option.

@atoulme I'm also proposing being a CODEOWNER with you in the otlpjsonfilereceiver, but please let me know if you agree with 🙏